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L27: Entry 1 of 1 File: TDBD Nov 1, 1S91 

TDB-ACC-NO: NN9111291 

DISCLOSURE TITLE: Representing Domain-Dependent Data in an Object-Oriented System. 
PUBLI CAT I ON - DAT A : 

IBM Technical Disclosure Bulletin, November 1991, US 

VOLUME NUMBER: 34 

ISSUE NUMBER: 6 

PAGE NUMBER: 291 - 300 

PUBLICATION-DATE: November 1, 1991 ( 19911101 ) 
CROSS REFERENCE: 0018-8689-34-6-291 
DISCLOSURE TEXT: 

- The Enabling Architecture is a general, modular, and flexible software 
architecture. It is the result of an investigation of alternative design strategies 
for Release 1.0 of Extended Services, which includes the Communications Manager. 
The initial goal was to eliminate some of the fundamental limitations of 
Communications Manager configuration; however, the software architecture described 
here is applicable to other products as well. Characteristics of the new Enabling 
Architecture include: Unification of redundant architectures. - Support for a 
vertical team organization. - Facilitation of code reuse. - Support for multiple 
configuration files and configuration file formats. - Separation of the user 
interface from the configuration data. - Support for new function. - Implementation 
of an open architecture. - Preparation for later convergence with AIX* . - The 
Enabling Architecture is an architecture designed to meet most or all of these 
goals. It is an object-oriented architecture consisting of two main pieces: a 
topology graph showing the relationships between objects such as hardware 
information, user data, configuration files, and the communications features 
installed by the user, and a C API implementing the methods used to access the 
objects in the topology. - The architecture is not tailored for use only by 
configuration; it can be used by runtime or by any code that needs to access the 
objects without regard for how or where they are stored. In fact, the architecture 
does not even assume that the context is Communications .Manager; it was designed to 
be generic, for application in other areas as well. THE TOPOLOGY The topology is 
defined as the internal organizational structure of the objects in the system. It 
reflects the functional dependencies between the objects, and allows an object to 
obtain information easily about other objects related to it. It is represented by 
an acyclical directed graph (the topology graph) consisting of objects of the 
system and the relationships between them. (Note: the topology graph is NOT a class 
hierarchy. That is, the links between nodes in the graph do not represent IS_A or 
subclass relationships.) The topology graph provides the architecture with several 
important benefits: - It provides a concrete representation of installation 
dependencies; for example, it shows that CPI-C requires that APPC be installed, 
that SRPI sits on top of 3270, etc. - - It provides a mechanism for doing both 
partial and complete verification of objects in an organized fashion. - - It 
facilitates the division of design and development work on the objects into 
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vertical teams, small teams of developers focusing on one component of the product 
all the way from design through test. This allows for independence of structures, 
method, implementation,, and file f ormats,>, whide^providing ■ a., f ormalism_.f or the design 
of a common layer (the C API). - - It provides a context from which error handling 
and the content of error messages for the user can be improved. - - It provides a 
context from which help handling for the user can be improved. THE TOPOLOGY GRAPH 
The nodes of the topology graph correspond to objects installed in the system. The 
links represent relationships between the nodes based on the object types; for 
example, a link between a system object (i.e., Com_object) and a feature object 
indicates that the feature is installed for that product; a link between a feature 
and a component indicates that the component is a configurable piece of the 
feature. The topology is represented by an acyclical directed graph instead of a 
tree in order to permit the sharing of child nodes between objects in the 
hierarchy . Note that this does not contradict the tree structure of a class 
hierarchy, since the topology graph is not a class hierarchy . - Information used by 
Communications Manager configuration is stored in two places: - Actual 
configuration information is stored in the configuration files. All values of 
configuration parameters that the user sets are stored in one or more files. (For 
EXTD/2 Release 1.0, it is assumed that there is one .CFG file and one .INI file; 
for Release 2.0, configuration data may be distributed among several files.) - 
Organizational information is. stored in the topology. This includes data regarding 
what features are installed in the machine, whether or not a feature (or any 
object) is verified or configured, what dependencies a feature has on other 
features, etc. - In particular, if a user wants to set a parameter to a particular 
value, he would (directly or indirectly) use information from the topology to 
determine where that parameter is stored, and then he would store the value in the 
specified configuration file. - Figure 1 contains a sample topology graph for a 
fictional release of Communications Manager, as it might appear with all known 
features installed. (Note that most of the lower-level nodes are omitted from the 
picture.) The root node of the graph is Com_object, the set of all objects 
associated with Communication Manager. If other products, such as Database and LAN, 
were to implement a similar or compatible topology, it would be feasible to have 
something called "OS/2_obj ect" as the start node of a graph, possessing the 
topologies headed by the objects Com_object, DB_object, and LAN_object as 
subgraphs. - All objects below the Com_object level represent parts of the product 
that are installed into the topology by the user. For instance, when 5250 is 
installed, a new node is created in the topology to represent the new product, 
along with the new nodes comprising its entire subgraph. A link is made between the 
5250 node and Com_object, as well as a link to APPC indicating its dependency. 
OBJECTS IN THE TOPOLOGY Every node in the graph corresponds to an object . There 
are eight object types defined for Com_objects: - System objects are repositories 
for system-level attributes and methods. For CM, the only system object is 
Com_object. - - Feature objects are installable objects that correspond to products 
or major pieces of a system object; for example, Communications Manager would have 
features such as APPC, Gateway, or Async. Features are always internal nodes of the 
topology graph, although they do not always come off the root node. - - Component 
objects are subparts of features that must be con figured by the user, such as a 
logical link, a session, or the SNA base. Components can be terminal ' nodes on the 
topology graph if no instances of them have been created yet; otherwise, they are 
parents of terminal nodes. - - Instance objects are the actual copies of objects 
that have been created by the user. For example, if a user configures three local 
logical units named LLU1, LLU2, and LLU3, then these are three instances of the 
component. Local_LU. Instances are always terminal nodes of the topology graph. 
(Note: an "in stance object" is NOT the same thing as an "instance" in object- 
oriented design, although the terms are similar.) - User objects describe user- 
dependent data. They may be con side red analogous to a "login" file or a " PROFILE " 
file on a mainframe. Instances of user_objects typically describe characteristics 
such as the user's selected color choices, settings for environment variables, etc. 
- - Machine objects describe machine-dependent data. - Instances of machine_ob j ects 
could contain the machine's model number, hardware information, etc. The EXTD/2 
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Release 1.0 workstation profile is an instance of a machine object. - - File 
objects are repositories for methods that apply to groups of files. For CM, the 

...only file, object is. file .It self . File.. instance, objects *a re xegular^f iles^ 

associated with Configuration and/or install. The purpose of including this as an 
object type is to allow access to a file as an entity itself, as opposed to 
addressing the contents of a file. Methods for a file instance would allow it to be 
opened, closed, copied, or deleted. File attributes may include its size, type, or 
date of creation. - Every object in the topology graph also possesses an identical 
set of attributes . The table below summarizes the attributes for Release 1.0; more 
may be added later for Release 2.0. Attribute Objects Values Meaning lock_state all 
LOCKED (1) or If the lock_state is LOCKED, OPEN (0). The a password is required in 
default is OPEN, order to access the node and the subgraph below. verify_state all 
TRUE or FALSE. TRUE is the node and its The default is subgraph are verified. The 
FALSE, value of Verify_state is also TRUE if the value of Config_state is FALSE; 
i.e., if the feature is not con- figured yet. config_state all TRUE or FALSE. TRUE 
if the node and its The default is subgraph are configured. - FALSE. auto_start 
features TRUE or FALSE. TRUE if this feature is to The default is be automatically 
started False when the system is brought up. hidden instances TRUE or FALSE. TRUE 
if the instance is The default is named by the user (as False opposed to being 
provided by the system), size File any nonnegative file size, in bytes. - integer. 
load_state File LOADED (1) or LOADED if the file is FILED (0). memory resident. 
feature_list File list. of feature indicates which installed node names, features 
contribute to the contents of this file. code_type Features RUNTIME, CONFIG, 
indicates what type of code or both, is installed for this feature, version 
Features valid version indicates the version number of number of the product 
product, associated with this feature. FRAMES Each object of type component has a 
special structure associated with it called a frame . A frame is not an instance 
object, but instead contains information describing the contents of instances. The 
frame contains the rules used to convert the (user-supplied) name of an instance 
into internal format, if necessary. It also contains a de- scriptor for every 
attribute associated with the component. Each descriptor consists of: - the name of 
the attribute. - the attribute type. - the range of the attribute, specified as an 
upper and lower bound, ("(0,0)" if no range checking is to be done). - a pointer to 
the conversion routine for the attribute. (A null pointer indicates that the 
conversion will not be done here, but rather, in the object's method.) 

SECURITY: Use, copying and distribution of this data is subject to the restictions in the Agreement For 
IBM TDB Database and Related Computer Databases. Unpublished - all rights reserved under the Copyright 
Laws of the United States. Contains confidential commercial information of IBM exempt from FOIA 
disclosure per 5 U.S.C. 552(b) (4) and protected under the Trade Secrets Act, 18 U.S.C. 1905. 

COPYRIGHT STATEMENT: The text of this article is Copyrighted (c) IBM Corporation 1991. All rights 
reserved. 
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DOCUMENT -IDENTIFIER: US 6578014 Bl 

TITLE: Method and apparatus for post-transaction pricing system 
Abstract Text (1) : 

The present invention is a method and apparatus for effectuating post- transaction- 
priced transactions of information, goods, and services in exchange for money or 
its equivalent ( such ..as credits). The invention allows prospective .sellers of 
information, goods and services to offer those items globally to potential buyers, 
for buyers to make item requests of sellers, for sellers and buyers conveniently to 
search for relevant buyer and seller information, for sellers to provide items to 
buyers without any guarantee of a specific payment amount, and for buyers to decide 
how much to pay for those items after having received them. The method and 
apparatus of the present invention have applications on the internet as well as 
conventional communications systems such as voice telephony. In a preferred 
embodiment, the method and apparatus of the present invention include mechanisms 
through which information about participants and previous transactions is revealed 
in such a way as to encourage buyers to pay a fair amount for the items provided, 
and to encourage sellers to provide items that are of high value to the buyers to 
whom they provide those items. Specifically, the system stores information 
regarding previous transactions and makes this information available to 
participants, so that they are able to intelligently decide which participants are 
worth transacting with. For example, a buyer who routinely pays nothing for items 
will soon have difficulty finding sellers interested in selling him/her items, 
while a buyer who consistently pays a fair price for items will be able to expect a 
steady stream of items. Similarly, a seller who consistently provides items which 
buyers are willing to pay large amounts for will have greater ability to provide 
items to buyers in the future, while a seller who provides items which buyers 
generally find worthless will have great difficulty finding any buyers to provide 
items to. 

Application Filing Date (1) : 
20000413 

Brief Summary Text (25) : 

The present invention is a method and apparatus for effectuating post- transaction- 
priced transactions of goods, services, and information in exchange for money or 
its equivalent (such as credits). The invention allows prospective sellers,.of ...... 

information, goods and services to offer those items globally to potential buyers, 
for buyers to make item requests of sellers, for sellers and buyers conveniently to 
search for relevant buyer and seller information, for sellers to provide items to 
buyers without any guarantee of a specific payment amount, and for buyers to decide 
how much to pay for those items after having received them. 

Brief Summary Text (26) : 

The method and apparatus of the present invention have applications on the internet 
as well as conventional communications systems such as voice telephony. Each 
participant can communicate with the system from remote terminals adapted to access 
communication links and the system may include remote terminals adapted for storage 
of a remote database . The system includes a database which contains participant and 
transaction information. The database is accessed via a validation procedure to 
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permit transactions in an interactive online mode between users during interactive 
transaction sessions wherein one participant to the transaction is specifically 
selected by. the - othe.r- : participant . The system ..permits -concurrent .interactive t t. J .^«^« 
business transaction sessions between different participants. 

Brief Summary Text (27): 

In one embodiment of the present invention, communications between buyers and 
sellers are conducted using an electronic network and a system operator. A seller 
who wishes to sell an item accesses the system operator located at a remote server. 
The seller then specifies the item he/she wishes to sell, searches for buyers who 
might be interested in receiving such an item, and provides a description of the 
item (if the item is goods or services) or either a description of the item or the 
item itself (if the item is information) to those buyers. For example, a typical 
item could be a well-researched article about a specific subject, on which the 
seller is an expert. The seller searches and identifies one or more buyers who 
might be interested in the article, and then either provides the article or a 
description of it to the buyer (s). Under the present invention, the information may 
be transmitted via numerous means including a world wide web interface, email, 
voicemail, facsimile, or postal mail. Alternatively, the information may be 
developed while the seller is online with the system operator. The system operator 
then assigns a unique tracking ID to the item and the item is sent to each buyer 
that the seller specified. Subsequently, the buyer logs on to the system, views 
items that have been provided to him/her, and optionally specifies payment amounts 
for those items or requests additional information from the seller (s). After the 
buyer has sent the payment to the system operator to cover the item(s) , the system 
operator sends a payment to the seller (s). Various methods of payment may be 
utilized by the invention, including credit cards, personal checks, electronic 
funds transfer, debit cards, digital cash, and escrow accounts. 

Drawing Description Text (7) : 

FIG. 5a illustrates one embodiment of the Items database ■ 
Drawing Description Text (8) : 

FIG. 5b illustrates another embodiment of the Items database in which additional 
item information is included. 

Drawing Description Text (9) : 

FIG. 6a illustrates one embodiment of the Sellers database . 
Drawing Description Text (10) : 

FIG. 6b illustrates another embodiment of the Sellers database in which additional 
seller information is included. 

Drawing Description Text (11): 

FIG. 7a illustrates one embodiment of the Buyers database . 
Drawing Description Text (12): 

FIG. 7b illustrates another embodiment of the Buyers database in which additional 
buyer information is included. 

Drawing Description Text (13) : 

FIG. 8 illustrates one embodiment of the Buyer Item Requests database . 
Drawing Description Text (14): 

FIG. 9 illustrates one embodiment of the System Payments to Sellers database . 
Drawing Description Text (15): 

FIG. 10 illustrates one embodiment of the Buyer Payments to System database . 
Drawing Description Text (16) : 
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FIG. 11 illustrates one embodiment of the Kicked Out database. 



Drawing.- Description- Text >.( 2.1,) ...^..^.r.u^ i. -.. .c*. >, .„ s v „, „ , 

FIG. 16 illustrates one embodiment of the Buyer Searches For Sellers form, which 
enables buyers to search the database to find sellers who might have items, 
demographics and/or areas of expertise of interest to the buyers. 

Drawing Description Text (27) : 

FIG. 22 illustrates one embodiment of the Seller Searches For Buyers form, which 

enables sellers to search the database to find buyers who might want the items the 

sellers have or can obtain. 

Detailed Description Text (2) : 

Throughout this document, the term "item" is used to mean information, goods and/or 
services that are being provided by the buyer and to the seller in a single 
transaction. An item can be anything of potential value. Note that the first type 
of item, information, will sometimes be a pointer to the actual information (ex. a 
web site location or the name of a book or article), rather than the actual 
information itself. In a preferred embodiment, a single item can include 
information, goods, services, or any combination of the three. In other words, 
"item" for the purposes of the present invention can actually consist of multiple 
items within a single transaction. 

Detailed Description Text (3) : 

Throughout this document, the term "information" is used to mean any non-physical 
item other than a service. For example, information could be text, software, 
graphics, audio, video, or in another format, or in a combination of different 
formats. 

Detailed Description Text (4) : 

Throughout this document, the term "buyer" is used to mean a recipient of an item 
(for a given transaction), or an individual, a corporation, a partnership, a 
government, a software agent, or any other entity which has been, or has expressed 
interest in being, a recipient of items. 

Detailed Description Text (5) : 

Throughout this document, the term "seller" is used to mean a provider of an item 
(for a given transaction), or an individual, a corporation, a partnership, a 
government, a software agent, or any other entity which has been, or has expressed 
interest in being, a provider of items. 

Detailed Description Text (11): 

The method and apparatus of the present invention will now be discussed with 
reference to FIGS. 1, 2, 3, and 4. In a preferred embodiment, the present invention 
includes system operator 200, buyer's inte rf ace . 300, seller's interface 400 and 
associated databases . 

Detailed' Description Text (17): 

As shown in FIG. 2, system operator 200 includes central processor (CPU) 202, RAM 
206, ROM 208, payment processor 212, clock 204, operating system 210, network 
interface 214, and data storage device 220. As is conventionally known in the art, 
the ROM provides software instructions to perform basic operations upon power up of 
the system. Once the system receives these instructions, the CPU reads operating 
system instructions stored on disk to configure the system and to permit execution 
of various applications programs. Other applications conventionally known may be 
included in the software environment. A personal computer or computer workstation 
with sufficient memory and processing capability may be used as system operator 
200. In one embodiment system operator 200 operates as a server, both receiving 
information from and transmitting information to buyers and sellers. System 
operator 200 must be capable of high volume transaction processing, performing a 
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significant. number of mathematical calculations in processing communications and 
database searches . A microprocessor such as Intel's Pentium III, or a similar 
v-cx microprocessor from. Advanced. .Micro- Devices^or^another^vendor,, may ^ be .used., for. CPU ... ^ 
202. 

Detailed Description Text (18): 

Referring again to FIG. 2, payment processor 212 comprises one or more standard 
microprocessors (such as those from Intel) , supporting the transfer and exchange of 
payments, charges, or debits, attendant to the method of the apparatus. Payment 
processor 212 may also be configured as part of CPU 202. Processing of credit card 
transactions by payment processor 212 may be supported with commercially available 
software, such as Open Market's Transact, which provides a complete set of end-to- 
end commerce services including online customer authentication and authorization, 
online order and payment processing, automated tax and shipping calculations, and 
online order tracking and status. 

Detailed Description Text (19) : 

Data storage device 220 may include hard disk magnetic or optical storage units, as 
well as CD-ROM drives or flash memory. Data storage device 220 contains databases 
used in the processing of transactions and the storing and retrieval of 
information, including Items Database 500, Sellers Database 600, Buyers Database 
700, Buyer Item Requests 800, System Payments to Sellers Database 900, Buyer 
Payments to System Database 1000, and Kicked Out Database 1100. The data 
illustrated in FIGS. 5-11 are representative of a preferred embodiment but might 
differ somewhat in any specific implementation. In a preferred embodiment a 
commercially available database management system with scalability and flexibility, 
such as Oracle's Oracle8 or Microsoft's SQL Server, is used to create and manage 
these databases . Security is implemented to prevent misuse by participants. Steps 
are taken to keep all information secure, especially payment data. In a preferred 
embodiment, these databases are all in the same Database Management System (DBMS), 
while in another embodiment they are distributed among multiple DBMSes. In some 
embodiments, some of the information which in a preferred embodiment is stored in 
the databases in data storage device 220 is instead stored on the buyers' and 
sellers' Data Storage Devices 320 (FIG. 3) and 420 (FIG. 4), respectively. This 
could be done for performance, security, or other reasons. 

Detailed Description Text (21): 

While the above embodiment describes a single computer acting as system operator 
200, those skilled in the art will realize that the functionality can be 
distributed over a plurality of computers. In one embodiment, system operator 200 
is configured in a distributed architecture, wherein the databases and processors 
are housed in separate units or locations. Some system operator components perform 
the primary processing functions and contain at a minimum RAM, ROM, and a general 
processor. Each of these components can be attached to a wire Area Network (WAN) 
hub serving as the primary communication link with the other components and 
interface devices. The WAN hub may have minimal processing capability itself, 
serving primarily as a communications router. Those skilled in the art will 
appreciate that an almost unlimited number of system operators may be supported. 

Detailed Description Text (22) : 

In one embodiment, system operator 200 has one or more pages on the World Wide Web, 
allowing buyers and sellers to provide and view information through the interface 
of conventional web browser software such as Netscape Navigator or Microsoft 
Internet Explorer. Instead of a world wide web-based interface, buyers and sellers 
may also send and receive information and items via electronic mail, voice mail, 
facsimile, or postal mail transmissions. With voice mail, the buyer or seller calls 
system operator 200 and leaves the information in audio form. This information may 
be transcribed into digital text at system operator 200, or made available to 
potential sellers in the same audio format. In a postal mail embodiment, system 
operator 200 acts more like a router, directing information to the buyers and 
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sellers, creating multiple copies of the information if necessary. The information 
may also be posted to bulletin boards or web pages operated by system operator 200. 
System <,opera tar ,.-20i)x,suppoc.ts. a. plurality^ of tr.ansmission, ; methods^.allowing 1 ^£ 1 or..a. . 
vide variety of formats of information. Some formats may be changed, however, 
before further processing by system operator 200. Information transmitted by mail 
in paper form, for example, may be scanned-in and digitized, using optical 
character recognition software to create digital text. 

Detailed Description Text (23): 

In one embodiment, information sent from one participant to another through the 
system (items, item requests, questions and replies) may go through a series of 
processing steps. One step, if necessary, is language translation, either creating 
a standard language that- all information must be written in, or translating to the 
language most appropriate for the buyers and sellers who will view it. This 
translation is provided by language experts at system operator 200, or by automatic 
translation software . Another step, if necessary, is to edit the information for 
spelling or grammatical errors and clarity. Any unclear information could be 
returned to the sender for clarification. 

Detailed Description Text (24): 

FIGS. 3 and 4 describe buyer's interface 300 and seller's interface 400, 
respectively. In an exemplary embodiment they are both standard personal computers 
having one or more input devices, such as a keyboard, mouse, and/or voice 
recognition software ; a display device, such as a video monitor; a processing 
device such as a CPU; and a network interface such as a modem. These devices 
interface with system operator 100 as in FIG 1. Alternatively, buyer's interface 
300 and seller's interface 400 may also be voicemail systems, fax machines, 
personal digital assistants (PDAs) with wireless connections, beepers, pagers or 
other electronic or voice communications systems. 

Detailed Description Text (25) : 

Referring now to FIG. 3, there is described buyer's interface 300 which includes 
central processing unit (CPU) 312, RAM 302, ROM 304, clock 306, video driver 308, 
display device 340, communications port 314, input device 350, modem 104, and data 
storage device 320. An Intel microprocessor such the Pentium III may be used for 
CPU 312. Clock 306 is a standard chip-based clock which can serve to time-stamp any 
specific action a buyer takes, such as assigning a payment amount or asking a 
seller a question. Data storage device 320 is a conventional magnetic-based hard 
disk storage unit such as those manufactured by Seagate or Quantum. In some 
embodiments, some of the information which in a preferred embodiment is stored in 
the databases in data storage, device 220 is instead stored on the buyers' Data 
Storage Device 320. This could be done for performance, security, or other reasons. 

Detailed Description Text (26) : 

Referring now to FIG. 4, there is described seller's interface 400 which includes 
central processing unit (CPU) 412, RAM 402, ROM 404, clock 406, video driver 408, 
display device 440, communications port 414, input device 450, modem 102, and data 
storage device 420. An Intel microprocessor such the Pentium III may be used for 
CPU 412. Clock 406 is a standard chip-based clock which can serve to time-stamp any 
specific action a seller takes, such as providing an item to a buyer or responding 
to a buyer's question about an item. Data storage device 420 is a conventional 
magnetic-based hard disk storage unit such as those manufactured by Seagate or 
Quantum. In some embodiments, some of the information which in a preferred 
embodiment is stored in the databases in data storage device 220 (FIG. 2) is 
instead stored on the sellers' Data Storage Device 420. This could be done for 
performance, security, or other reasons. 

Detailed Description Text (27): 

There are many commercial software applications that can enable the communications 
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required by buyer's interface 300 and seller's interface 400, the primary 
functionality being message creation and transmission. Qualcomm' s Eudora Pro 
, provides. ..tools. _f.or.,,the. acea.tio.n..o£ s! ..mes.aag.ea ^as^w.ell. as v .t he -routing, .of ..those. ^ 
messages to the appropriate electronic address. When system operator 200 is 
configured as a web server, conventional communications sof tware such as 
Microsoft's Internet Explorer web browser may also be used. The buyer and seller 
may use the Internet Explorer browser to send information to and receive 
information from the system operator. No proprietary software is required. The 
system operator can use off-the-shelf software and hardware for its web server, and 
can create the forms, pages and screens in FIGS. 13-29 and 31-32 as web pages using 
off-the-shelf software, such as Microsoft Notepad, Netscape Composer, Microsoft 
FrontPage, Allaire ColdFusion, and other similar products. The web pages are hosted 
either in-house or by a site hosting service, with the appropriate software . 

Detailed Description Text (30) : 

In one embodiment, a buyer or a seller can put certain data (especially that data 
which relates to one's own transactions) in a format easy to copy to other 
applications (e.g. report writing, or saving as a spreadsheet file or database 
file) . 

Detailed Description Text (31): 

Referring to FIG. 5a, Items Database 500 maintains data on items that sellers are 
willing to sell, such as Item ID 502, Buyer ID 504, Seller ID 506. Item 508, Date 
Item Description Provided 510, Date Item Provided 512, Payment Amount 514, Payment 
Date 516, Buyer Payments To System ID 518, System Payments To Sellers ID 520, 
Status 522 and Correspondence 524. In a preferred embodiment, Items Database 500 
has one record (row) for each item. Item ID 502 is a unique identifier for the 
item. Buyer ID 504 stores the numerical ID from Buyers Database 700 corresponding 
to the buyer for this transaction. Seller ID 506 stores the numerical ID from 
Sellers Database 600 corresponding to the seller for this transaction. Item 508 
stores a description of the item, as it was entered by the seller through Seller 
Provides Item form 2300 (FIG. 23). If the item is information (as opposed to goods 
or services) , this data may be the actual information the item consists of; or it 
may be a pointer to the item, such as a web page URL (e.g. 

http://www.sitename.com/pagename.html) or a book or magazine article (e.g. Business 
Week, Jan. 1, 1999, p. 100). Date Item Description Provided 510 stores the date on 
which the data in Item 508 was supplied by the seller. Date Item Provided 512 
stores the date on which the item was provided by the seller. For items which are 
information, this date will usually be the same as Date Item Description Provided 
510. For goods and services, this date might differ from Date Item Description 
Provided 510. Payment Amount 514 stores the amount that the buyer decides to pay 
for the item. Payment Date 516 stores the date on which the buyer assigns the 
payment amount for this item. Note that the date the payment is actually made from 
the buyer to the system operator to pay for this item doesn't need to be stored in 
this table, since it can always be found in the Buyer Payments To System database 
1000 (FIG. 10) . 

Detailed Description Text (32) : 

Buyer Payments To System ID 518 stores the numerical ID from Buyer Payments To 
System database 1000 corresponding to the payment from the buyer to the system 
operator which includes the payment for this item. There will usually be a one-to- 
many correspondence between a buyer's payments to the system operator and a buyer's 
payment assignments for specific items; in other words, a buyer will make one large 
payment to the system operator in order to cover the payments for several items at 
once. System Payments To Sellers ID 520 stores the numerical ID from System 
Payments To Sellers database 900 corresponding to the payment from the system 
operator to the seller which pays for this amount. There will usually be a one-to- 
many correspondence between the system operator's payments to a seller and the 
seller's assigned payments from various buyers for various items; in. other words, a 
seller will receive one large payment from the system for a lot of items he/she 
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provided. Status 522 stores the current status of this item (e.g. 'delivered but 
price not yet set 4 ). Correspondence 524 stores communications back and forth, if 
-i-any,-...,b-etween, the..buyer.,and^seller -regarding., this, iiem...,,^^.^ ........ , 

Detailed Description Text (33): 

Referring to FIG. 5b, in various embodiments, some information is stored in this 
database in addition to that shown in FIG. 5a. Here are some examples of additional 
data which exist in some embodiments and which could be stored in this database 
(note that for numbered drawing elements which appear in both FIG. Sa and FIG. 5b, 
the numbers refer to the same elements in both): Item Type 550 stores information 
on what type of item the item is. Types can vary in various embodiments. For 
example, in one embodiment Item Type 550 stores either 4 information 4 , 'goods*, or 
'services 4 . In another embodiment, Item Type 550 could store more specific 
information, such as % information: stock research : earnings prediction 4 . In a 
preferred embodiment, the system operator has the ability to change item types that 
he/she feels have been set incorrectly. Conditions 552 stores information on any 
specific conditions on the sale of the item, imposed by the seller; for example, 
how delivery will occur. Suggested Payment 554 stores a suggested payment amount 
that the seller can optionally provide for the buyer, which the buyer is free to 
consider or disregard. Request ID 556 is Item Request ID 802 (FIG. 8) for those 
items which sellers offered in response to a buyer's item request; otherwise it is 
null. 

Detailed Description Text (34): 

Referring to FIG. 6a, Sellers database 600 maintains data on individuals, companies 
and other entities which are or want to be sellers, such as Seller ID 602, Company 
Name 604, Veb Site URL 606, First Name 608, Last Name 610, User Name 612, Password 
614, Phone 616, Email 618, Address 620, City/State 622, Zip 624, Country 626, 
Date/Time Joined 627, Balance 628, Preferences 630, and Comments 632. In a 
preferred embodiment, Sellers database 600 has one record (row) for each seller: 
Seller ID 602 is a unique identifier for the seller. Company Name 604 stores the 
name of the company if the seller is a company, otherwise it is blank. Web Site URL 
606 is the URL for the home page of the company's web site if the company has a web 
site, otherwise it is blank. First Name 608 stores the first name of the seller, or 
the first name of the primary contact person if the seller is a company: Last Name 
610 stores the last name of the seller, or the last name of the primary contact 
person if the seller is a company. User Name 612 stores the name by which the 
seller will be identified throughout the system. Password 614 stores the password 
which the seller will use to gain access to areas which are password-protected and 
areas which require authenticated identification. Phone 616 stores the phone number 
of the seller. Email 618 stores the email address of the seller. Address 620 stores 
the postal address of the seller (e.g. 123 Main Street). City/State 622 stores the 
city and state of the seller. Zip 624 stores the zip code of the seller. Country 
626 stores the country of the seller. Date/Time Joined 627 stores the date and time 
when the seller joined the system. Balance 628 stores the current balance of the 
seller, which is owed to him/her by the system operator. Preferences 630 stores the 
seller's preferences about the various settings within the system which the seller 
has full or partial control over, such as the format in which various information 
is displayed. Comments 632 stores any comments that the system operator enters 
about the seller. 

Detailed Description Text (35): 

In various embodiments, some of this information is stored on seller's interface 
400, such as through a text file, database file or a "cookies" file. 

Detailed Description Text (36): 

Referring to FIG. 6b, in various embodiments, some information is stored in this 
database in. addition to that shown in FIG. 6a. Here are some examples of additional 
data which exist in some embodiments and which could be stored in this database 
(note that for numbered drawing elements which appear in both FIG. 6a and FIG. 6b, 
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the numbers refer to the same elements in both): Birth Date 650 stores information 
on when the person was born, to be used to confirm that the seller is of legal age, 
. no.t^a. mi-nar, . Gender 652 stores-. Xnf.ormati on. about.whe thex..-the.r ; sellerr,^(or. .the primary, 
contact person if the seller is a company) is male or female, demographic 
information that might be of use to some buyers. Occupation 654 stores information 
about what occupation the seller is (or what type of company the seller is, if the 
seller is a company) , demographic information that might be of use to some buyers. 
Education Level 656 stores information about what education level the seller 
achieved (if the seller is an individual), demographic information that might be of 
use to some buyers. Household Income 658 stores information about the approximate 
annual household income of the seller (if the seller is an individual), demographic 
information that might be of use to some buyers. Areas of Expertise 660 stores 
information about the specific areas of expertise of the seller and/or types of 
items the seller has or is likely to be able to provide, information that might be 
of use to some buyers. In one embodiment, there is an additional table to store 
detailed information about seller expertise or specific types of items that a 
seller has for sale. The expertise or items could be classified according to 
type/category. In one optional feature of this embodiment, there are several levels 
of expertise for a given skill or area (i.e. expert, significant experience, some 
experience, etc.). In another optional feature of this embodiment, a seller has to 
pass a test or meet certain other qualifications in order to qualify as an expert. 
In another optional feature of this embodiment, penalties are imposed for sellers 
who claimed to be experts in a specific area but later turned out not to be, either 
by not having the claimed specific qualifications or by not having a sufficiently 
high average payment for transactions of the type in which the seller claimed to be 
an expert. Vant Newsletter 662 stores information about whether the seller wants to 
receive periodic emails from the system operator about general system news and 
related information. Why Joined 664 stores information about why the seller joined 
the system, which might be useful to the system operator for marketing purposes. 
How Found 666 stores information about how the seller discovered the system, which 
might be useful to the system operator for marketing purposes. Other Contact Info 
668 stores information about other ways to contact the seller, such as pager 
number, voicemail address, and fax number. Credit Card Info 670 stores the seller's 
credit card information, for the purposes of identification or for embodiments 
which allow sellers to receive payments by credit card. Bank Account Info 671 
stores the seller's bank account information, for the purposes of identification or 
for embodiments which allow sellers to receive payments directly to their bank 
accounts. Social Security Number 672 stores the seller's social security number if 
the seller is an individual, or a company's Federal Employer Identification Number 
if the seller is a company, for the purposes of identification. Payment Preference 
674 lets the seller indicate how he/she prefers to receive payment for items, for 
embodiments which allow multiple payment methods. Anonymous 676 lets the seller 
choose to remain anonymous, identified only by a consistent ID rather than his/her 
name or company name. For numerous privacy and competitive reasons, sellers might 
prefer not to have their identities revealed to the general public when engaging in 
commercial transactions. 

Detailed Description Text (37) : 

Referring to FIG. 7a, Buyers database 700 maintains data on individuals, companies 
and other entities which are or want to be buyers, such as Buyer ID 702, Company 
Name 704, Web Site URL 706, First Name 708, Last Name 710, User Name 712, Password 
714, Phone 716, Email 718, Address 720, City/State 722, Zip 724, Country 726, 
Date/Time Joined 727, Balance 728, Preferences 730, Comments 732, and Seller ID 
734. In a preferred embodiment, Buyers database 700 has one record (row) for each 
buyer. Buyer ID 702 is a unique identifier for the buyer. Company Name 704 stores 
the name of the company if the buyer is a company, otherwise it is blank. Web Site 
URL 706 is the URL for the home page of the company's web site if the company has a 
web site, otherwise it is blank. First Name 708 stores the first name of the buyer, 
or the first name of the primary contact person if the buyer is a company. Last 
Name 710 stores the last name of the buyer, or the last name of the primary contact 
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person if the buyer is a company. User Name 712 stores the name by which the buyer 
will be identified throughout the system. Password 714 stores the password which 
~the.-buyex~ will-use^to-gain^access .to-., areas.~w.hich- a re. t .pas sword-protected uand^ateas,,.. 
which require authenticated identification. Phone 716 stores the phone number of 
the buyer. Email 718 stores the email address of the buyer. Address 720 stores the 
address of the buyer (e.g. 123 Main Street). City/State 722 stores the city and 
state of the buyer. Zip 724 stores the zip code of the buyer. Country 726 stores 
the country of the buyer. Date/Time Joined 727 stores the date and time when the 
buyer joined the system. Balance 728 stores the current balance of the buyer, if 
the total payments the buyer has made to the system operator exceed the amounts the 
buyer has paid for items he/she purchased. Preferences 730 stores the buyer's 
preferences about the various settings within the system which the buyer has full 
or partial control over, such as the format in which various information is 
displayed. Comments 732 stores any comments that the system operator enters about 
the buyer. Seller ID 734 stores the same number as the Seller ID 602 if the buyer 
also happens to be a seller, which is permitted in a preferred embodiment. 

Detailed Description Text (38) : 

In various embodiments, some of this information is stored on buyer's interface 
300, such as through a text file, database file or a "cookies" file. 

Detailed Description Text (39): 

Referring to FIG. 7b, in various embodiments, some information is stored in this 
database in addition to that shown in FIG. 7a. Here are some examples of additional 
data which exist in some embodiments and which could be stored in this database 
(note that for numbered drawing elements which appear in both FIG. 7a and FIG. 7b, 
the numbers refer to the same elements in both): Cutoff Percentile 750 stores the 
minimum percentile cutoff of eligible sellers for this buyer. This is the value 
that the buyer has entered, indicating the lowest acceptable percentile of sellers, 
in terms of their average payments received for items. In a preferred embodiment, 
sellers below this threshold are not able to provide items to the buyer. Birth Date 
752 stores information on when the person was born, to be used to confirm that the 
buyer is of legal age, not a minor. Gender 754 stores information about whether the 
buyer (or the primary contact person if the buyer is a company) is male or female, 
demographic information that might be of use to some sellers. Occupation 756 stores 
information about what occupation the buyer is (or what type of company the buyer 
is, if the buyer is a company), demographic information that might be of use to 
some sellers. Education Level 758 stores information about what education level the 
buyer achieved (if the buyer is an individual), demographic information that might 
be of use to some sellers. Household Income 760 stores information about the 
approximate annual household income of the buyer (if the buyer is an individual) , 
demographic information that might be of use to some sellers. Want Newsletter 762 
stores information about whether the buyer wants to receive periodic emails from 
the system operator about general system news and related information. Why Joined 
764 stores information about why the buyer joined the system, which might be useful 
for marketing purposes. How Found 766 stores information about how the buyer 
discovered the system, which might be useful for marketing purposes. Other Contact 
Info 768 stores information about other ways to contact the buyer, such as pager 
number, voicemail address, and fax number. Credit Card Info 770 stores the buyer's 
credit card information, for the purposes of identification or for embodiments 
which allow buyers to make payments by credit card. Bank Account Info 771 stores 
the buyer's bank account information, for the purposes of identification or for 
embodiments which allow buyers to make payments directly from their bank accounts. 
Social Security Number 772 stores the buyer's social security number if the buyer 
is an individual, or a company's Federal Employer Identification Number if the 
buyer is a company, for the purposes of identification. Payment Preference 774 lets 
the buyer indicate how he/she prefers to make payments for items, for embodiments 
which allow multiple payment methods. Anonymous 776 lets the buyer choose to remain 
anonymous, identified only by a consistent ID rather than his/her name or company 
name. For numerous privacy and competitive reasons, buyers often prefer not to have 
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their identities revealed to the general public when engaging in commercial 
transactions . 



Detailed Description Tent (40): 

In some embodiments, such as those in which a significant proportion of 
participants sometimes act as a buyers and sometimes as sellers, the Sellers 
database 600 and Buyers database 700 arc replaced by a single database . 

Detailed Description Text (41): 

Referring to FIG. 8, Buyer Item Requests database 800 maintains data on requests 
that buyers make for items and types of items (in those embodiments which allow for 
such requests), such as Item Request ID 802, Buyer ID 804, Date/Time 806, 
Description 808, and Status 810. One example of an item request would be the answer 
to a specific question: in this case, the item that the buyer is requesting is the 
answer to the question. In a preferred embodiment, Buyer Item Requests database 800 
has one record (row) for each item or type of item requested by each buyer. Item 
Request ID 802 is a unique identifier for the item request. Buyer ID 804 is the 
number corresponding to Buyer ID 702 for the buyer making the item request. 
Date/Time 806 stores the date and time at which the item request was made. 
Description 808 stores a description of the requested item, type of item, or area 
of expertise. Status 810 stores the current status of the item request. For 
example, the status could be 'open* or 'closed', and if it's closed then Status 810 
also indicates the value for Item ID 502 corresponding to the item which fulfilled 
the request. 

Detailed Description Text (42) : 

In some embodiments, Buyer Item Requests database 800 is not used and the 
information it includes is instead included in Buyers database 700. 

Detailed Description Text (43): 

Referring to FIG. 9, System Payments To Sellers database 900 maintains data on 
payments made by the system operator to sellers, such as System Payment ID 902, 
Seller ID 904, Date/Time 906, and Payment 908. In a preferred embodiment, System 
Payments to Sellers database 900 has one record (row) for each payment the system 
operator makes to any seller. System Payment ID 902 is a unique identifier for each 
system payment. Seller. ID 904 stores the value in Seller ID 602 for the seller who 
received or will receive the payment. Date/Time 906 stores the date and time at 
which the payment is made from the system operator to the seller. Payment 908 
stores the amount of the payment. 

Detailed Description Text (44): 

Referring to FIG. 10, Buyer Payments To System database 1000 maintains data on 
payments made by buyers to the system operator, such as Buyer Payment ID 1002, 
Buyer ID 1004, Date/Time 1006, and Payment 1008. In a preferred embodiment, Buyer 
Payments To System database 1000 has one record (row) for each payment a buyer 
makes to the system operator. Buyer Payment ID 1002 is a unique identifier for each 
buyer payment. Buyer ID 1004 stores the value in Buyer ID 702 for the buyer who 
made or will make the payment. Date/Time 1006 stores the date and time at which the 
payment is made from the buyer to the system operator. Payment 1008 stores the 
amount of the payment. 

Detailed Description Text (45): 

Referring to FIG. 11, Kicked Out database 1100 maintains data on which participants 
have been kicked out of the system, such as for rule violations, and should not be 
allowed to rejoin (in those embodiments which track such information), such as 
Buyer Or Seller 1102, Buyer Or Seller ID 1104, Date/Time 1106, and Comments 1108. 
In a preferred embodiment, Kicked Out database 1100 has one record (row) for each 
buyer or seller who has been kicked out of the system. Buyer Or Seller 1102 stores 
information on whether the participant was a buyer, a seller, or both. Buyer Or 
Seller ID 1104 stores the value in Seller ID 602 for this participant if he/she was 
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a seller, or the value in Buyer ID 702 for this participant if he/she was a buyer 
or both a buyer and a seller. Date and Time 1106 stores the date and time when the 
participant^was. kicked out .of . the. system., .Comments 1108..stores~details about, why. 
the participant was kicked out of the system, and is entered by the system 
operator . 

Detailed Description Text (46): 

In some embodiments, Kicked Out database 1100 is not used and the information it 
includes is instead included in Sellers database 600 and Buyers database 700. In a 
preferred embodiment, poorly performing participants (based on a variety of 
criteria, such as low average payments for buyers or sellers, or a significant 
number of late or missed payments for buyers) and rule violators can be removed 
from the system and/or other sanctions can be imposed. 

Detailed Description Text (48): 

Referring now to FIG. 12, there is described one embodiment of the flow of 
information and payments related to a given transaction in the system. Before a 
transaction can occur between a buyer and a seller, each must join the system (1202 
and 1204 respectively) and enter some profile information (1206 and 1208 
respectively). In a preferred embodiment, this is done through Buyer Registration 
form 1400 and Seller Registration form 2000. In a preferred embodiment, the 
participant can join and enter the profile information at the same time, or can 
join and then later enter his/her profile information. In another embodiment, both 
must be entered at the same time. 

Detailed Description Text (49): 

The steps involved in a single transaction in a preferred embodiment are 
illustrated in Transaction Process 1210. In a preferred embodiment, a transaction 
can begin in two different ways: either a buyer requests a specific item from a 
seller using Buyer Item Request form 1700, probably after searching using Buyer 
Searches For Sellers form 1600, or a seller provides an item or a description of an 
item using Seller Provides Item form 2300 (1212 and 1213 respectively) . In the 
former case (1212) , the seller then either provides the item or a description of 
the item using Seller Provides Item form 2300, or provides a different item or a 
description of a different item using Seller Provides Item form 2300, or chooses 
not to provide the item or description in which case the transaction ends (1213, 
1214, and 1215 respectively). These actions of the buyer and seller are stored in 
Items database 500. 

Detailed Description Text (55): 

Referring to FIG. 14, there is described one embodiment of the Buyer Registration 
form, which enables individuals, companies and other entities to register to 
participate as buyers in the system. The form includes Company Name, Site Name (for 
those participants which have web sites) , URL (for those participants which have 
web sites) , Category (which lets them indicate which category or categories they 
might want to express an interest in being a buyer of items for), Date/Time (which 
is filled in automatically), Name 1410, Password 1412, Phone Number, Email Address, 
Postal Mail Address, Initial Payment, Preferred Payment Method 1413, and Additional 
Payment Information 1415. In a preferred embodiment, the buyer acknowledges that by 
registering and using the system, he/she understands that transactions he/she 
enters into form legally binding contracts, tfhen a buyer registers, the system 
compares Kicked Out database 1100 with Sellers database 600 and Buyers database 700 
to see if a buyer or seller with the same first name and last name, company name, 
address, credit card number, and/or Social Security number has already been kicked 
out of the system. If the buyer has not already been kicked out of the system and 
the buyer meets any other requirements, the buyer is accepted into the system and 
the information he/she entered is placed in Buyers database 700. In a preferred 
embodiment, this form also enables an existing buyer to update his/her information. 
In one embodiment, this form also includes an Item Request link 1417, which takes 
him/her to Buyer Item Request form 1700, enabling him/her to make item requests. 
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Detailed Description Text (58): 

t Rafexring to ,FLG..... 15, stiver e.. is. described one.*.emb.odim.ent fc .. of. ..Buyer Login^f oriruJ.500., ... 
through which buyers enter their Name (1410 in FIG. 14) and Password (1412 in FIG. 
14) in order to log in to the system (1502). The Buyers database is checked to 
confirm that the Name and Password that have been entered correspond to a 
registered buyer. If login is successful, they can perform a variety of activities 
such as: click on Buyer Searches For Sellers link 1504 to go to Buyer Searches For 
Sellers form 1600; click on Buyer Item Request link 1506 to go to Buyer Item 
Request form 1700; click on Buyer Views Items link 1508 to go to Buyer Views Items 
page 1800; and click on Buyer Account Information link 1510 to go to Buyer Account 
Information page 1900. The buyer can also click on Buyer Specifies Acceptable 
Sellers 1512 to go to Buyer Specifies Acceptable Sellers form 3200 to specify, 
characteristics of sellers that the buyer is willing to accept items from. In one 
embodiment, the buyer can also click on Top Listings link 1514 to go to Top 
Listings page 2800. Update Registration Information 1516 enables the buyer to 
change some of the registration information he/she entered upon initially joining 
the system. In some embodiments, various other information which would be of use to 
buyers is included on this page. 

Detailed Description Text (60): 

Referring to FIG. 16, there is described one embodiment of Buyer Searches For 
Sellers form 1600, which enables buyers to search the database for specific types 
of sellers and/cr items. FIG. 16 shows some examples of searches this form might 
allow, such as : searching all sellers 1602; searching by items 1604 (which would 
show information, goods, services, or all three); searching by area of expertise 
1606; searching by occupation 1608; searching by specific text 1610; 
searching/screening by seller's average payment 1612; searching/screening by 
seller's number of completed transactions 1614; and searching by comments other 
participants have made about a seller, for embodiments which include this feature 
(1615) . Multiple search criteria can be specified, enabling buyers to search for 
very specific types of sellers and/or items, for example: displaying all items that 
are services from sellers whose occupation is lawyer and whose average payment is 
greater than $5 and whose number of completed transactions is at least 20. Such 
queries can be written with standard SQL to return records from the various 
databases in Data Storage Device 220. The results of the search (1616) are 
displayed, either on the same page or on a subsequent page, in such a way that the 
buyer is able to initiate a transaction by clicking on one of them and going to 
Buyer Item Request form 1700 (for those embodiments which include this form) and 
making an item request. 

Detailed Description Text (61): 

In a preferred embodiment, some subset of the information about participating 
sellers and buyers is available to sellers, some subset of the information about 
participating sellers and buyers is available to buyers (primarily through Buyer 
Searches For Sellers form 1600 in FIG. 16, Seller Searches For Buyers form 2200 in 
FIG. 22, Top Listings page 2800 in FIG. 28, and Participant Directory 2900 in FIG. 
29), and some information is not made available to anyone other than the system 
operator. In one embodiment, contact information such as phone number, email 
address, and possibly the participant's name are not made public, either for all 
participants (this is designed to enable the system to discourage 
disintermediation, in which the participants bypass the system and transact 
business directly) or for those who want it (some participants might want 
anonymity) . In some embodiments, a participant has partial control over what 
information about that participant is available to others through the system. For 
example, if anonymity is desired, a participant's ID rather than the person's or 
company's name might be displayed. 

Detailed Description Text (62): 

Some- information regarding a given buyer's or seller's earlier transactions can be 
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viewed by buyers and sellers (and sometimes even visitors who aren't yet 
participants), in order to enable other buyers and sellers to better determine 
.whether . they^wish^ta .eater*. into - transac.tio.ns -with. .the buyer .or-s.elle r . .^Suctwdata^ 
may include (in some embodiments) but not be limited to: number of transactions; 
average payment (in a preferred embodiment , - mean payment is used; in another 
embodiment, median payment or some other calculated average is used) ; timeliness of 
payments (e.g. percent assigned on time, percent paid on time,, percent ever paid); 
and comments and/or ratings from those who have transacted with that buyer/seller. 
In one embodiment, when searching the database for potential transactions, buyers 
and/or sellers are able to screen by this type of criteria. 

Detailed Description Text (66) : 

Referring to FIG. 17, there is described Buyer Item Request form 1700, which exists 
in some embodiments. It enables buyers to specify items they would like to buy. 
They can indicate specific items (1702) or types of items (1704) . They can also 
indicate what types of sellers they are interested in buying such items from: a 
specific seller or list of specific sellers (1706); a type or types of sellers 
(1708); or other required seller criteria (1710). In some embodiments, there is one 
standard form for buyers to make item requests, but there are also a variety of 
other item request templates (1712) for specific categories, classes, and types of 
item requests, such as: a. web site testing and feedback b. document review (for 
grammar, professionalism, legal, etc.) c. specific question answering, help, advice 
d. request for resources (books, sites, etc.) for a specific subject or question e. 
research request, fact checking, survey completion f . consultant needed, contract 
work g. recruiting employees h. new product names i. any type of activity that is 
companies often outsource j. product wanted to. purchase k. anything that people 
often have trouble finding (i.e. lead generation, affiliate programs, and big- 
ticket items like houses, apartments, or cars) 1. specific requests: a buyer can 
make a request for item suggestions, one or more of which will be selected (in one 
embodiment, a buyer can indicate that he/she might be willing to pay a certain 
amount or an approximate amount for the best response they receive (ex. for new 
product name, an ad campaign idea, a slogan, a jingle, etc.), or he/she can split 
that between sellers, whatever way the buyer wants. The buyer can also make a 
request without an indication of expected payment.) 

Detailed Description Text (67) : 

Each of the above types of specific request forms has some required fields and/or 
some optional fields, which one skilled in the art could create without difficulty. 
The entered information is stored in Buyer Item Requests database 800, or in some 
embodiments could be stored in a separate database . In one embodiment, sellers who 
meet the required criteria receive the item request, either by being alerted or by 
seeing it on Seller Searches For Buyers form 2200. In one embodiment, a buyer can 
optionally provide guidance about what payment amount they might be willing to pay 
for the desired item (1714). 

Detailed Description Text (71) : 

In a preferred embodiment, the buyer has a predetermined amount of time after the 
information is entered in which to assign the payment (if any) , and a predetermined 
amount of time (either after the information is entered or after the payment is 
assigned) in which to pay (in the non-prepayment embodiment) . In a preferred 
embodiment, for transactions in which the buyer and seller are corresponding about 
the item, the clock 4 resets to zero* (i.e. the buyer again has the full amount of 
time) when the seller sends a message; in another embodiment, the clock doesn't 
reset; in another embodiment, the clock is only "ticking" when the seller is 
waiting for a message from the buyer and not the reverse (similar to the way a 
chess clock functions). In one embodiment, the notification that the buyer receives 
about the information also mentions that this payment clock has begun, and the 
system operator can give the buyer another notification just before the time 
expires. In embodiments requiring prepayment, there obviously are not any payments 
made late (although some payment amounts might still be assigned late) . In such 
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cases, each buyer has his/her own billing date, probably once per month (or all 
buyers have the same billing date, probably once per month) . All payments assigned 
.. by -that date.-will be .billed,. in a siag I.e.. .billion, .that date . ..T>he^buyer^ will. have. -a.... - 
predetermined number days to pay the bill. If they don't pay on time, the payments 
for all those items will be set to zero, but if the buyer later pays, those items 
will be set to the correct numbers (the database will differentiate between an 
assigned zero payment and a late-payment zero payment) . In one embodiment, sellers 
are paid by the system operator on a regular basis, provided they are owed at least 
some minimum amount. In one embodiment, buyers have to pay an additional fee for 
late payments. In one embodiment, payments can be non-cash, such as products, 
services, product discounts, or system credits. 

Detailed Description Text (74): 

If the seller later replies to the buyer's request for additional information by 
entering it in 2416 on FIG. 24, that information will appear in 1816. In one 
embodiment, a buyer has the ability to return to this form and change payment 
amounts that he/she previously assigned, up to the time the payment is made; in 
another embodiment, a buyer cannot change a payment amount once it is assigned; in 
another embodiment, a buyer can raise a payment amount, but cannot lower it, once 
it he/she initially sets it. In one embodiment, if the item corresponds to an Item 
Request that the buyer has made, the buyer can close the item request (1818) so 
that no other sellers provide items in response to the item request. The data 
entered on this form is written to, and the data displayed on this form is taken 
from, Items database 500. If the buyer decides to send a note to the seller, 
information about the seller, including his/her contact information, is read from 
Sellers database 600. In one embodiment, the page includes for each communication 
between buyer and seller any relevant reference IDs (possibly linked) to earlier 
communications, for that item and/or for all previous interactions between that 
buyer and that seller. In one embodiment, a buyer has the option (but not the 
obligation) to assign a payment amount and/or make payment before receipt of the 
item. For example, a buyer might receive a description of an item (such as a good 
or service) from a seller, and decide to assign a payment amount and/or make 
payment before receipt of the actual item (in other words, the buyer can use the 
pay-after- receipt technique of the present invention for some items and the more 
conventional pay-before- receipt technique for others) . 

Detailed Description Text (77) : 

Referring to FIG. 19, there is described one embodiment of Buyer Account 
Information page 1900, which enables a buyer to check his/her account information, 
including Name, current Date/Time, and Current Account Balance. The page also 
displays various account metrics, such as the buyer's average payment, number of 
items bought, average time to pay, and percentage of payments made on time. The 
page also displays a list of payments the buyer made and the dates on which those 
payments were made. The data displayed on this page are taken from Buyer Payments 
To Syste m database 1000 and Items database 500. The page also lets buyers make 
payments to cover their item purchases (1910). Payments are made by buyers to the 
system operator. There will usually be a one-to-many correspondence between a 
buyer's payments to the system operator and a buyer's payment assignments for 
specific items; in other words, a buyer will make one large payment to the system 
operator in order to cover the payments for a lot of items all at once. In a 
preferred embodiment, payments by buyers to the system operator can be made by 
check and/or credit card. In another embodiment, a micropayment system is an option 
for the buyer. In one embodiment, a buyer must prepay the system operator an amount 
which will be used to pay for subsequent items through a declining balance method. 
In another embodiment, a buyer will not have to prepay but will have to pay the 
system operator at regular intervals or once a certain balance due has been 
reached. In one optional feature of those embodiments which allow but don't require 
buyer prepayment, sellers have access to information about whether a given buyer 
has a positive balance in his/her account, i.e. whether the buyer will be paying 
immediately. This would encourage buyers to keep a positive balance, since sellers 
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would be more inclined to provide items to buyers for whom payment from the buyer 
to the system operator would occur immediately. 

Detailed Description Text (80): 

Skipping ahead to FIG. 32, there is described Buyer Specifies Acceptable Sellers 
form 3200, which exists in some embodiments. It enables buyers to specify that only 
certain sellers are able to provide items to him/her. The criteria the buyer has to 
choose from can include the following: accept all sellers (3202); accept those in 
certain areas of expertise and not others, perhaps by choosing Yes or No from a 
scrolling list of all areas of expertise (3204); accept those in certain 
occupations, perhaps by choosing Yes or No from a scrolling list of all occupations 
(3206); accept those who have an average payment of at least a certain amount, or 
an average payment of at least a certain percentile of all sellers (3208); accept 
those who have completed at least a certain number of transactions and/or at most* a 
certain number of transactions (3210). Multiple search criteria can be specified, 
enabling buyers to be very specific about which sellers they are willing to accept 
items from. Such queries can be written with standard SQL to return records from 
the various databases in Data Storage Device 220. 

Detailed Description Text (81): 

Referring to FIG. 20, there is described one embodiment of Seller Registration form 
2000, which enables individuals, companies and other entities to register to 
participate as sellers in the system. The form includes Company Name, Site Name 
(for those participants which have web sites), URL (for those participants which 
have web 1 sites), Date/Time (which is filled in automatically), Name 2010, Password 
2012, Phone Number, Email Address, Postal Mail Address, Occupation, Education 
Level, Areas of Expertise (site design, graphics, database, programming, marketing, 
email newsletters, tax, law, finance, or just about any other area of expertise), 
Preferred Payment Method 2013 (for those embodiments that allow more than one 
payment method), and Additional Payment Info 2015. In a preferred embodiment, the 
buyer acknowledges that by registering and using the system, he/she understands 
that transactions he/she enters into form legally binding contracts. 

Detailed Description Text (82) : 

When a seller registers, the system compares Kicked Out database 1100 with Sellers 
database 600 and Buyers database 700 to see if a buyer or seller with the same 
first name and last name, company name, address, credit card number, and/or Social 
Security number has already been kicked out of the system. If the seller has not 
already been kicked out of the system and the seller meets any other requirements, 
the seller is accepted into the system and the information he/she entered is placed 
in Sellers database 600. In a preferred embodiment, this form also enables an 
existing seller to update his/her information. In one embodiment, this form also 
includes a Provide Items link 2023, which takes them to Seller Provides Item form 
2300, enabling them to provide items right away. 

Detailed Description Text (85) : 

Each of the above types of "items-available" template forms has some required 
fields and/or some optional fields and/or a place where sellers can add fields of 
their own. Each seller can fill in whichever ones are appropriate. The information 
entered could be stored as a separate table in Items database 500, Sellers database 
600, or another database . 

Detailed Description Text (86) : 

Referring to FIG. 21, there is described one embodiment of Seller Login form 2100, 
through which sellers enter their Name (2010 in FIG. 20) and Password (2012 in FIG. 
20) in order to log in to the system (2102). The Sellers database is checked to 
confirm that the Name and Password that have been entered correspond to a 
registered seller. If login is successful, they can perform a variety of activities 
such as: click on Seller Searches For Buyers link 2104 to go to Seller Searches For 
Buyers form 2200; click on Seller Provides Item link 2106 to go to Seller Provides 
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Item form 2300; click on Seller Views Items link 2108 to go to Seller Views Items 
page 2400; and click on Seller Account Information link 2110 to go to Seller 
- Account .-Information.. page. 2500. -In._one. .embodiment ,. the .seller,. can ..also^click- on .T.op ... 
Listings link 2112 to go to Top Listings page 2800. Update Registration Information 
2114 enables the seller to change some of the registration information he/she 
entered upon initially joining the system. In some embodiments, various other 
information which would be of use to sellers is included on this page. 

Detailed Description Text (87) : 

Referring to FIG. 22, there is described one embodiment of Seller Searches For 
Buyers form 2200, which enables sellers to search the database for specific types 
of buyers and/or items. FIG. 22 shows some examples of searches this form might 
allow, such as : searching all buyers 2202; searching by open item requests 2204 
(which would show only those item requests which haven't yet been satisfactorily 
fulfilled as specified by the buyer using Close Item Request 1818 in FIG. 18); 
searching by category of buyer 2206; searching by specific text 2208; 
searching/ screening by buyer's average payment 2210; searching/ screening by buyer's 
number of completed transactions 2212; searching by buyer's percentage of on-time 
payments 2214; and searching by comments other participants have made about a 
buyer, for embodiments which include this feature (2215) . Multiple search criteria 
can be specified, enabling sellers to search for very specific types of buyers 
and/or items, for example: displaying all items that include the word 
* nanotechnology* and are wanted by buyers whose average payment is greater than $3 
and who have made at least 8 0% of their payments on time. Such queries can be 
written with standard SQL to return records from the various databases in Data 
Storage Device 220. The search results 2216 would be displayed, either on the 
current page or another page, in such a way that the seller is able to initiate a 
transaction by clicking on one of them and going to Seller Provides Item form 2300 
to provide an item. In one embodiment, search results 2216 include information 
about what items other sellers have supplied in an attempt to satisfy the item 
request, and what the results were, so that they might build on these efforts and 
better learn what the buyer is looking for, rather than duplicating prior efforts. 
In a preferred embodiment, searching by open item requests 2204 will show only 
those item requests which the seller is capable of responding to, as determined by 
whether the seller meets the buyer's cutoff percentile requirement and any other 
specified requirements. In another embodiment, the seller would be able to view, 
but not to provide items for, item requests for which he/she does not meet the 
requirements . 

Detailed Description Text (88): 

Referring to FIG. 23, there is described one embodiment of Seller Provides Item 
form 2300. This form enables a seller to provide items to buyers through the 
system. In each transaction, the seller provides the item to one or more buyers, 
with the understanding that there is no guarantee of any specific compensation. In 
a preferred embodiment, only those buyers who are interested in receiving items 
from a seller who fits the description of this seller will appear on this form (as 
those buyers specified on Buyer Specifies Acceptable Sellers form 3200). For 
example, if a buyer specifies that he/she only wants items from sellers ' whose 
average payment is in the top 20% of all sellers, then sellers who don't meet this 
requirement are not able to specify such buyers on this form. The seller enters the 
actual item (if the item is information) or a description of the item (2302) , and 
specifies which of the available buyers the seller wants to sell the item to 
(2304). The item's description is entered into Items database 500. The seller then 
provides the specified item to the buyer. This could involve the delivery of 
physical goods as well as digital goods. 

Detailed Description Text (91): 

In one embodiment, the seller may list items that" he/she doesn't necessarily 
currently have; the offer is not binding, and in some cases will just be a 
description of what he/she might be able to provide. This can be done in order to 
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enable buyers to indicate an interest in the item. In one embodiment, a seller can 
provide descriptive information about an item or type of item and wait for a 
response from a-buye.r...4f or~.3JV-indi cation, -of interests estimation, .of . what -r»an.ge.-of..^ 
prices they might be willing to pay, etc.) before actually providing the item. In 
such embodiments, a buyer can view such information through Buyer Searches For 
Sellers form 1600. 

Detailed Description Text (92): 

Referring to FIG. 24, there is described one embodiment of Seller Views Items page 
2400, which enables a seller to view all the items which that seller has provided 
to buyers by filling out Seller Provides Item form 2300. For each such item, the 
page displays: the actual item if the item is information (2402) or a description 
of the item (2404); the buyer (2406); the date/time at which the seller provided 
the item (2408); the payment amount if it has been set by the buyer (2410); and 
date/time at which the payment amount was set, if the buyer has set it (2412). This 
page also displays a buyer's request for additional information about an item 
(2414), if the buyer has made such a request in 1814 on Buyer Views Items page 
1800. If the seller replies to the request by entering it in 2416, that information 
will appear in 1816 on Buyer Views Items page 1800. The data entered on this page 
is written to, and the data displayed on this page is taken from, Items database 
500. If the seller decides to send a note to the buyer, information about the 
buyer, including his/her contact information, is read from Buyers database 700. In 
one embodiment; the page includes for each communication between buyer and seller 
any relevant reference IDs (possibly linked) to earlier communications, for that 
item and/or for all previous interactions between that buyer and that seller. 

Detailed Description Text (95) : 

Referring to FIG. 25, there is described one embodiment of Seller Account 
Information page 2500, which enables a seller to check his/her account information, 
including Name, current Date/Time, and Current Account Balance. The page also 
displays various account metrics, such as the seller's number of items sold, 
average payment, average payment for each buyer the seller sold at least one item 
to, and outstanding payments (i.e. payments made by buyers to the. system operator 
but not yet received by the seller from the system operator) . The page also 
displays a list of payments the seller received and the dates on which those 
payments were received. The data displayed on this page are taken from System 
Payments To Sellers database 900 and Items database 500 and can be retrieved from 
the databases with standard SQL queries. 

Detailed Description Text (103) : 

Referring to FIG. 28, there is described Top Listings page 2800, which exists in 
some embodiments. This displays various rankings of participants, such as: top 
participants, based on some quantitative calculation (2802); buyers who have bought 
the largest number of items in the last X days, where X is some predefined number, 
and overall (2804); sellers who have sold the largest number of items in the last X 
days, and overall (2806); buyers who have the highest average payment (i.e. total 
payments divided by number of items) in the last X days, and overall (2808); 
sellers who have the highest average payment in the last X days, and overall 
(2810) ; buyers who have the highest total payments in the last X days, or overall 
(2812), and sellers who have the highest total payments in the last X days, and 
overall (2814) . The data displayed on this page is taken from Items database 500, 
Sellers database 600, and Buyers database 700, and can be taken from the databases 
using standard SQL queries. FIG. 28 is an exemplary illustration, and in some 
embodiments includes other listings such as items which received the highest 
payments, item types which received the highest average payments, and newest buyers 
and sellers to join the system. In one embodiment, the display differs depending on 
whether the participant was a buyer or a seller. This information could be 
collected automatically from the database, or could be collected manually by the 
system operator. This would help educate participants about what types of 
information receive high payments. In one optional feature of this embodiment, 
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buyers and/or sellers could specify that they don't want their transaction 
information reveal others in this manner. In one embodiment, the items receiving 
^the...highest- payments., in- th.e i ,.last>X..days^,.and ove rail,... are^di splayed.^ In,. one .^.^^^ 
embodiment, a participant can view the top listings out of those which meet 
criteria specified by the participant (for- example, top listings by lawyers, or top 
listings by participants in Virginia). 

Detailed Description Text (104) : 

Referring to FIG . 29, there is described Participant Directory 2900, which exists 
in some embodiments. The data displayed on this page is taken from Sellers database 
600 and Buyers database 700, and can be taken from the databases using standard SQL 
queries. Different embodiments include different information in this directory; 
FIG. 29 is an exemplary embodiment. In some embodiments, the directory includes a 
hierarchical classification system, which is included on the buyer's and seller's 
registration forms and stored in the database to be queried here. In some 
embodiments a participant can choose not to be listed here, while in other 
embodiments the listing is required. 

Detailed Description Text (107) : 

In one embodiment, in addition to relevant data about a given participant, some 
relevant data is also made available regarding specific classes of items for that 
participant (e.g. not just a participant's average payment, but their average 
payments for each class of item they've had transactions for) . 

Detailed Description Text (109) : 

Referring to FIG. 31, there is described one embodiment of System Operator View 
3100, which can be used by the system operator to get a high-level view of how the 
system is functioning, with details about transaction activity and buyer and seller 
behavior, to enable him/her to better manage the system. In an exemplary 
embodiment, information that can be viewed includes: average payment in a given 
period, average cutoff percentile, total number of buyers and sellers, number of 
new buyers and sellers in a given period, and number of new items provided in a 
given period; graphs of the distribution of buyer-specified cutoff percentiles, the 
distribution of number of items for each buyer, the distribution of number of items 
for each seller, the distribution of the average payment for each buyer, the 
distribution of the average payment for each seller, the distribution of the total 
payment amounts for each buyer, and the distribution of the total payment amounts 
for each seller; graphs of the correlation between a buyer's average payment and 
his/her number of items bought per unit time, the correlation between a buyer's 
average payment amount and his/her cutoff percentile, the correlation between a 
buyer's number of items bought per unit time and his/her cutoff percentile, and the 
correlation between a seller's number of items sold per unit time and his/her 
average payment. In a preferred embodiment, the system operator can monitor the 
transactions for rule violators and troublemakers, by using search tools and 
looking for unusual transaction behavior. The data displayed on this view are taken 
from Items database 500, Sellers database 600, and Buyers database 700, and can be 
retrieved from the databases with standard SQL queries. 

Detailed Description Text (121) : 

In one embodiment, there can be a plurality of participants on the buyer side or 
the seller side or both (either to act collectively in a single transaction, or in 
a plurality of transactions) . The system would enable participants to publish and 
3e arch for information about such multiple -buyer and multiple-seller situations, 
and would enable communications between such parties to coordinate their 
activities. In the case of a single transaction, the payment could be split as 
follows: each buyer decides what he/she wants to pay (if just one seller), or the 
one buyer decides how much each seller gets (if just one buyer); or in the case of 
multiple buyers and sellers, each buyer decides how much to give to each seller. In 
the case of a plurality of transactions, each could be handled exactly as in the 
preferred embodiment. In one optional feature of the plurality-of -transactions 
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embodiment, sellers would be able to see information that other sellers provided to 
a given buyer, so that the sellers might be able to collectively help the buyer 
better- than,.ifl..the. selle r,s< were .acting.-. Independently . In., anothe.r^embodiment, .they, ., 
would not be able to see such information, or they might only be able to see such 
information in some cases. 

Detailed Description Text (124) : 

In one embodiment, the buyer and/or the seller can give a feedback rating and/or 

provide comments about the other participant in the transaction that some or all 
other participants can later read and/or use as search criteria. 

Detailed Description Text (129) : 

In a preferred embodiment, some aggregate data (such as average payment amounts) 
are calculated dynamically, while some other aggregate data are calculated 
periodically (i.e. cached). The different calculation techniques might require 
different database schemas, which one skilled in the art would have no difficulty 
creating . 

Detailed Description Text (133) : 

As with software, web sites often have errors (called bugs) and potential 
enhancements. Often it is a site's visitor who discovers the bug or thinks of an 
enhancement. But currently that visitor has virtually no incentive to report the 
information to the site. The current invention could be used in a site testing and 
feedback network, in which site users and testers act as sellers of bug information 
and feedback to the sites, who act as buyers and optionally pay the sellers for the 
information and feedback provided. The goal would be to enable sites to receive all 
the high-quality feedback they need at a discount to its value to them, and to 
enable individuals to make money by providing such feedback, and to enable the 
system operator to take a share of the value unlocked, by establishing a vast 
network of sites and testers which allows them to efficiently accomplish their 
respective goals. 

Detailed Description Text (137) : 

Companies often need to conduct surveys of specific types of people, and it is 
currently quite expensive to do so because it is difficult to find people meeting 
the required criteria. The current invention could be used to enable companies to 
quickly find a group of qualified people to survey, and could make it easy for 
those people to fill out and submit the survey data. In this embodiment, companies 
would be able to specify which types of people qualify for the survey, from among 
the profile information (demographics, areas of expertise, etc.) which sellers 
supply upon joining. The system would enable companies to easily design custom 
surveys, and would simplify the aggregation and presentation of the survey data. In 
one embodiment, companies could provide an idea of how much they're willing to pay 
for completed surveys (e.g. a range, or a specific amount for sufficiently good 
ones and nothing for the rest, etc.) In this embodiment, the buyers would be the 
companies conducting the surveys and the sellers would be the individuals who 
filled out the surveys. As with the Veb Site Testing and. Feedback example, this 
example works well because the value of the information is much higher to the 
corporation (buyer) than the surveyed person (seller), so the transaction creates 
value which the buyer and seller can both benefit from. 

Current US Original Classification (1) : 
705/26 
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